Should this have an aria-label like I've added here because the placeholder is removed in readOnly state? @meganaconley @jacobdevera @prsdthkr

Can you show where it says not to include a placeholder? I'm looking at https://experience.sap.com/fiori-design-web/select/#readonly and it seems fine as-is.

I think the confusion may be that it seems to be a placeholder when it should actually be a pre-selected value.

For everyone else - sent wiki link privately as it's internal :)

We can set this one to be a selected item for the docs though?

Yeah, the text here could be changed to make clear that it's a selected item rather than a placeholder.

This shouldn't be running storybook on a pre-commit hook

This should be moved to separate PR

It already was - otherwise you wouldn't be able to commit anything 😉
#1067

Do these need any aria-hidden attributes? aria-label? or does the placeholder give enough information?

I think we should put a tabIndex of -1 on this. Otherwise we get two tab stops. The entire select should be a single tabstop as in this example: https://www.w3.org/TR/wai-aria-practices/examples/listbox/listbox-collapsible.html

That way it can be a button or a span, whichever is better for the visuals.

This was changed to a span to fix the duplicate tabbing issue (you can observe this now by tabbing into the Select component in this PR's deployment). I guess you could make an argument that anything with the fd-button class should be an actual button, but the parent being role="button" is sufficient for screen readers and keyboard users to use the component without majorly refactoring the styles.

Can you show where it says not to include a placeholder? I'm looking at https://experience.sap.com/fiori-design-web/select/#readonly and it seems fine as-is.

I think the confusion may be that it seems to be a placeholder when it should actually be a pre-selected value.

I think this should have tabindex="0" since readonly inputs are focusable for screen-reader purposes. Also I believe you removed the selected value by mistake.

<div class="fd-select__control" role="button" aria-expanded="false" aria-label="Potato" aria-haspopup="false" aria-readonly="true" tabindex="0">Potato</div>

This should be moved to separate PR

nothing changed in these besides the class on fd-list__item- I was just spreading them out so I could see what I was doing. Happy to put them back if anyone is bothered by it

This is where I still don't know what to do.. I've got the styling added via is-readonly class, but how do we communicate it's readonly? The ui5 one has a hidden input.

Additionally, I'm not sure how about not being able to open the popover - "Readonly elements are relevant to the user, and application authors SHOULD NOT restrict navigation to the element or its focusable descendants." https://www.w3.org/TR/2017/REC-wai-aria-1.1-20171214/#aria-readonly

I've been trying to look for other examples on the internet, and there doesn't appear to be anything like this surprisingly. I agree the language is a little vague on what to do for components with popups. We have a couple steps:

1. Like UI5, we can add a hidden input with aria-readonly as a child of the button. This is so screen readers can tell it is read-only when focused without have to click the button.

2. (optional?) Allow the popover to open in read only mode, and set aria-readonly on the ul listbox.

We should definitely do 1. 2 is potentially optional. The disappearance of the chevron in readonly suggests that it shouldn't be opened, and I can't find any mandate where the list of options needs to be presented in read-only mode.

EDIT: I was experimenting putting an inner input, but the readonly state is not read out when the button is focused. The inner input doesn't appear to help much at all. If I change the button itself to a role="combobox" with aria-readonly this reads as expected. The problem is that a Select effectively always has a readonly combobox as you can't edit the text directly, which further muddies the problem...

I think it's ok to say that a combobox is aria-readonly only when it's value can't be set. Technically you can't type in the box, but you can change its value. The definition in the link Jenna provided for aria-readonly says The user can set the value of the element. vs The user cannot change the value of the element. By that I don't think it's limited to actually typing only, but any sort of change in value whether it be selecting an option from a dropdown or a radio group, setting a checkbox, etc.

@meganaconley @jacobdevera Stupid question - but I'm not following 😆 What should the html look like?

@jbadan Yeah sorry, I was thinking out loud and got kinda convoluted 😅

Like UI5 (https://sapui5.hana.ondemand.com/#/entity/sap.m.Select/sample/sap.m.sample.Select), I would try to change to combobox instead of button because it supports aria-readonly :
<div class="fd-select__control is-readonly" role="combobox" aria-expanded="false" aria-label="Select" aria-haspopup="false" aria-readonly="true">Selected Item 2</div>

So this is what I was running into: https://www.w3.org/TR/wai-aria-1.1/#combobox

"Authors MUST ensure an element with role combobox contains or owns a text input element with role textbox or searchbox and that the text input has aria-multiline set to false. "

Technically, we are already breaking spec because we are not supplying an editable textbox input for the combobox in the first place; we're merely using combobox as a way to get aria-readonly to be supported. The spec mentions that the input must be a child of the combobox, not that the input can the combobox itself. In our case, if we supply the fake hidden input element like UI5 does, at best, it doesn't affect anything for screen reader callouts, and at worst, could be misleading for when the Select is not marked readonly.

Again, whether the base combobox is an input or div doesn't affect accessibility because the semantics are being overriden by the combobox role.

My take: I'm okay with adding a hidden input into a combobox, but only for the readonly state. All other select states should remain with the usual listbox in button as in the w3c example.

But what I'm trying to say - should we even be using role="combobox" if we're not following the spec?

This is starting to feel like too hacky of a workaround. We can also just table this and put an actual story in the backlog to investigate this further since we've spent so much time on it already.

Ideally, no. Agreed that it can wait for a future story.

UIA11Y-2324

It's not fiori3 compatible. First pictures on specifications are wrong.

Anyway, we don't use important at all. If this situation occurs, you would need to use stronger selector

So we don't need to have fd-select__item on every single item anymore.

Which spec do we want to follow as the source of truth? https://experience.sap.com/fiori-design-web/select/

I can only assume, that we should follow list component there. Same as with multi input or combobox. Let's ask designers maybe, because spec shows 2 different views.

Message is not visible anymore, it went behind select

.fd-dialog__body is missing position: relative

Should use @mixin fd-readonly